阿里技术|Java的这些坑，你踩到了吗？

作者：mobiledu2502860057 | 来源：互联网 | 2023-09-17 18:23

阿里妹导读：日常开发中总会遇到各种各样的“坑”，如何提前规避呢？本文将分享Java开发中容易遇到的一些坑，并给出详细的问题解

阿里妹导读&＃xff1a;日常开发中总会遇到各种各样的“坑”&＃xff0c;如何提前规避呢&＃xff1f;本文将分享 Java 开发中容易遇到的一些坑&＃xff0c;并给出详细的问题解析和避坑方法。

前言

中国有句老话叫"事不过三"&＃xff0c;指一个人犯了同样的错误&＃xff0c;一次两次还可以原谅&＃xff0c;再多就不可原谅了。写代码也是如此&＃xff0c;同一个代码“坑”&＃xff0c;踩第一次叫"长了经验"&＃xff0c;踩第二次叫"加深印象"&＃xff0c;踩第三次叫"不长记性"&＃xff0c;踩三次以上就叫"不可救药"。在本文中&＃xff0c;笔者总结了一些 Java 坑&＃xff0c;描述了问题现象&＃xff0c;进行了问题分析&＃xff0c;给出了避坑方法。希望大家在日常工作中&＃xff0c;遇到了这类 Java 坑&＃xff0c;能够提前避让开来。

1 对象比较方法

JDK 1.7 提供的 Objects.equals 方法&＃xff0c;非常方便地实现了对象的比较&＃xff0c;有效地避免了繁琐的空指针检查。

问题现象

在 JDK1.7 之前&＃xff0c;在判断一个短整型、整型、长整型包装数据类型与常量是否相等时&＃xff0c;我们一般这样写&＃xff1a;

Short shortValue &＃61; (short)12345; System.out.println(shortValue &＃61;&＃61; 12345); // true Integer intValue &＃61; 12345; System.out.println(intValue &＃61;&＃61; 12345); // true Long longValue &＃61; 12345L; System.out.println(longValue &＃61;&＃61; 12345); // true

从 JDK1.7 之后&＃xff0c;提供了 Objects.equals 方法&＃xff0c;并推荐使用函数式编程&＃xff0c;更改代码如下&＃xff1a;

Short shortValue &＃61; (short)12345; System.out.println(Objects.equals(shortValue, 12345)); // false Integer intValue &＃61; 12345; System.out.println(Objects.equals(intValue, 12345)); // true Long longValue &＃61; 12345L; System.out.println(Objects.equals(longValue, 12345)); // false

为什么直接把 &＃61;&＃61; 替换为 Objects.equals 方法就会导致输出结果不一样&＃xff1f;

问题分析

通过反编译第一段代码&＃xff0c;我们得到语句 System.out.println(shortValue &＃61;&＃61; 12345); 的字节码指令如下&＃xff1a;

getstatic java.lang.System.out : java.io.PrintStream [22] aload_1 [shortValue] invokevirtual java.lang.Short.shortValue() : short [28] sipush 12345 if_icmpne 24 iconst_1 goto 25 iconst_0 invokevirtual java.io.PrintStream.println(boolean) : void [32]

原来&＃xff0c;编译器会判断包装数据类型对应的基本数据类型&＃xff0c;并采用这个基本数据类型的指令进行比较&＃xff08;比如上面字节码指令中的 sipush 和 if_icmpne 等&＃xff09;&＃xff0c;相当于编译器自动对常量进行了数据类型的强制转化。

为什么采用 Objects.equals 方法后&＃xff0c;编译器不自动对常量进行数据类型的强制转化&＃xff1f;通过反编译第二段代码&＃xff0c;我们得到语句 System.out.println(Objects.equals(shortValue, 12345)); 的字节码指令如下&＃xff1a;

getstatic java.lang.System.out : java.io.PrintStream [22] aload_1 [shortValue] sipush 12345 invokestatic java.lang.Integer.valueOf(int) : java.lang.Integer [28]invokestatic java.util.Objects.equals(java.lang.Object, java.lang.Object) : boolean [33] invokevirtual java.io.PrintStream.println(boolean) : void [39]

原来&＃xff0c;编译器根据字面意思&＃xff0c;认为常量 12345 默认基本数据类型是 int&＃xff0c;所以会自动转化为包装数据类型 Integer。

在 Java 语言中&＃xff0c;整数的默认数据类型是 int&＃xff0c;小数的默认数据类型是 double。

通过分析Objects.equals方法的源代码可知&＃xff1a;语句 System.out.println(Objects.equals(shortValue, 12345))&＃xff0c;因为 Objects.equals 的两个参数对象类型不一致&＃xff0c;一个是包装数据类型 Short&＃xff0c;另一个是包装数据类型 Integer&＃xff0c;所以最终的比较结果必然是false&＃xff1b;而语句 System.out.println(Objects.equals(intValue, 12345))&＃xff0c;因为 Objects.equals 的两个参数对象类型一致&＃xff0c;都是包装数据类型 Integer 且取值相同&＃xff0c;所以最终的比较结果必然是 true。

避坑方法

1&＃xff09;保持良好的编码习惯&＃xff0c;避免数据类型的自动转化

为了避免数据类型自动转化&＃xff0c;更科学的写法是直接声明常量为对应的基本数据类型。

第一段代码可以这样写&＃xff1a;

Short shortValue &＃61; (short)12345; System.out.println(shortValue &＃61;&＃61; (short)12345); // true Integer intValue &＃61; 12345; System.out.println(intValue &＃61;&＃61; 12345); // true Long longValue &＃61; 12345L; System.out.println(longValue &＃61;&＃61; 12345L); // true

第二段代码可以这样写&＃xff1a;

Short shortValue &＃61; (short)12345; System.out.println(Objects.equals(shortValue, (short)12345)); // true Integer intValue &＃61; 12345; System.out.println(Objects.equals(intValue, 12345)); // true Long longValue &＃61; 12345L; System.out.println(Objects.equals(longValue, 12345L)); // true

2&＃xff09;借助开发工具或插件&＃xff0c;及早地发现数据类型不匹配问题

在 Eclipse 的问题窗口中&＃xff0c;我们会看到这样的提示&＃xff1a;

Unlikely argument type for equals(): int seems to be unrelated to Short Unlikely argument type for equals(): int seems to be unrelated to Long

3&＃xff09;进行常规性单元测试&＃xff0c;尽量把问题发现在研发阶段

“勿以善小而不为”&＃xff0c;不要因为改动很小就不需要进行单元测试了&＃xff0c;往往 Bug 都出现在自己过度自信的代码中。像这种问题&＃xff0c;只要进行一次单元测试&＃xff0c;是完全可以发现问题的。

注意&＃xff1a;进行必要单元测试&＃xff0c;适用于以下所有案例&＃xff0c;所以下文不再累述。

2 三元表达式拆包

三元表达式是 Java 编码中的一个固定语法格式&＃xff1a;

条件表达式&＃xff1f;表达式1&＃xff1a;表达式2

三元表达式的逻辑为&＃xff1a;如果条件表达式成立&＃xff0c;则执行表达式 1&＃xff0c;否则执行表达式 2。

问题现象

boolean condition &＃61; false; Double value1 &＃61; 1.0D; Double value2 &＃61; 2.0D; Double value3 &＃61; null; Double result &＃61; condition ? value1 * value2 : value3; // 抛出空指针异常

当条件表达式 condition 等于 false 时&＃xff0c;直接把 Double 对象 value3 赋值给 Double 对象 result&＃xff0c;按道理没有任何问题&＃xff0c;为什么会抛出空指针异常&＃xff1f;

问题分析

通过反编译代码&＃xff0c;我们得到语句&＃xff1a;

Double result &＃61; condition ? value1 * value2 : value3;

的字节码指令如下&＃xff1a;

iload_1 [condition] ifeq 33 aload_2 [value1] invokevirtual java.lang.Double.doubleValue() : double [24] aload_3 [value2] invokevirtual java.lang.Double.doubleValue() : double [24] dmul goto 38 aload 4 [value3] invokevirtual java.lang.Double.doubleValue() : double [24] invokestatic java.lang.Double.valueOf(double) : java.lang.Double [16] astore 5 [result]

在第 9 行&＃xff0c;加载 Double 对象 value 3 到操作数栈中&＃xff1b;在第 10 行&＃xff0c;调用 Double 对象 value 3 的 doubleValue 方法。这个时候&＃xff0c;由于 value 3 是空对象 null&＃xff0c;调用 doubleValue 方法必然抛出抛出空指针异常。但是&＃xff0c;为什么要把空对象 value 3 转化为基础数据类型 double 呢&＃xff1f;

查阅相关资料&＃xff0c;得到三元表达式的类型转化规则&＃xff1a;

若两个表达式类型相同&＃xff0c;返回值类型为该类型&＃xff1b;

若两个表达式类型不同&＃xff0c;但类型不可转换&＃xff0c;返回值类型为 Object 类型&＃xff1b;

若两个表达式类型不同&＃xff0c;但类型可以转化&＃xff0c;先把包装数据类型转化为基本数据类型&＃xff0c;然后按照基本数据类型的转换规则 &＃xff08;byte

根据规则分析&＃xff0c;表达式 1&＃xff08;value1 * value2&＃xff09;的类型为基础数据类型 double&＃xff0c;表达式 2&＃xff08;value 3&＃xff09;的类型为包装数据类型 Double&＃xff0c;根据三元表达式的类型转化规则判断&＃xff0c;最终的表达式类型为基础数据类型 double。所以&＃xff0c;当条件表达式 condition 为 false 时&＃xff0c;需要把空 Double 对象 value 3 转化为基础数据类型 double&＃xff0c;于是就调用了 value 3 的 doubleValue 方法进行拆包&＃xff0c;当然会抛出空指针异常。

避坑方法

1&＃xff09;尽量避免使用三元表达式&＃xff0c;可以采用 if-else 语句代替

如果三元表达式中有包装数据类型的算术计算&＃xff0c;可以考虑利用 if-else 语句代替。改写代码如下&＃xff1a;

if (condition) {result &＃61; value1 * value2; } else {result &＃61; value3; }

2&＃xff09;尽量使用基本数据类型&＃xff0c;避免包装数据类型的拆装包

如果在三元表达式中有算术计算&＃xff0c;尽量使用基本数据类型&＃xff0c;避免包装数据类型的拆装包。改写代码如下&＃xff1a;

boolean condition &＃61; false; double value1 &＃61; 1.0D; double value2 &＃61; 2.0D; double value3 &＃61; 3.0D; double result &＃61; condition ? value1 * value2 : value3;

3 泛型对象赋值

Java 泛型是 JDK 1.5 中引入的一个新特性&＃xff0c;其本质是参数化类型&＃xff0c;即把数据类型做为一个参数使用。

问题现象

在做用户数据分页查询时&＃xff0c;因为笔误编写了如下代码&＃xff1a;

1&＃xff09;PageDataVO.java

/** 分页数据VO类 */ &＃64;Getter &＃64;Setter &＃64;ToString &＃64;NoArgsConstructor &＃64;AllArgsConstructor public class PageDataVO {/** 总共数量 */private Long totalCount;/** 数据列表 */private List dataList; }

2&＃xff09;UserDAO.java

/** 用户DAO接口 */ &＃64;Mapper public interface UserDAO {/** 统计用户数量 */public Long countUser(&＃64;Param("query") UserQueryVO query);/** 查询用户信息 */public List queryUser(&＃64;Param("query") UserQueryVO query);}

3&＃xff09;UserService.java

/** 用户服务类 */&＃64;Service public class UserService {/** 用户DAO */&＃64;Autowiredprivate UserDAO userDAO;/** 查询用户信息 */public PageDataVO queryUser(UserQueryVO query) { List dataList &＃61; null;Long totalCount &＃61; userDAO.countUser(query);if (Objects.nonNull(totalCount) && totalCount.compareTo(0L) > 0) {dataList &＃61; userDAO.queryUser(query);}return new PageDataVO(totalCount, dataList);} }

以上代码没有任何编译问题&＃xff0c;但是却把 UserDO 中一些涉密字段返回给前端。细心的读者可能已经发现了&＃xff0c;在 UserService 类的 queryUser 方法的语句 return new PageDataVO(totalCount, dataList); 中&＃xff0c;我们把 List 对象 dataList 赋值给了 PageDataVO 的 List 字段 dataList。

问题是&＃xff1a;为什么开发工具不报编译错误啦&＃xff1f;

问题分析

由于历史原因&＃xff0c;参数化类型和原始类型需要兼容。我们以 ArrayList 举例子&＃xff0c;来看看如何兼容的。

以前的写法&＃xff1a;

ArrayList list &＃61; new ArrayList();

现在的写法&＃xff1a;

ArrayList list &＃61; new ArrayList();

考虑到与以前的代码兼容&＃xff0c;各种对象引用之间传值&＃xff0c;必然会出现以下的情况&＃xff1a;

// 第一种情况 ArrayList list1 &＃61; new ArrayList(); // 第二种情况 ArrayList list2 &＃61; new ArrayList();

所以&＃xff0c;Java 编译器对以上两种类型进行了兼容&＃xff0c;不会出现编译错误&＃xff0c;但会出现编译告警。但是&＃xff0c;我的开发工具在编译时真没出现过告警。

再来分析我们遇到的问题&＃xff0c;实际上同时命中了两种情况&＃xff1a;

把 List 对象赋值给 List&＃xff0c;命中了第一种情况&＃xff1b;

把 PageDataVO 对象赋值给 PageDataVO&＃xff0c;命中了第二种情况。

最终的效果就是&＃xff1a;我们神奇地把 List 对象赋值给了 List。

问题的根源就是&＃xff1a;我们在初始化 PageDataVO 对象时&＃xff0c;没有要求强制进行类型检查。

避坑方法

1&＃xff09;在初始化泛型对象时&＃xff0c;推荐使用 diamond 语法

在《 Java 开发手册》中&＃xff0c;有这么一条推荐规则&＃xff1a;

【推荐】集合泛型定义时&＃xff0c;在 JDK7 及以上&＃xff0c;使用 diamond 语法或全省略。
说明&＃xff1a;菱形泛型&＃xff0c;即 diamond&＃xff0c;直接使用<>来指代前边已经指定的类型。

正例&＃xff1a;

// <> diamond 方式 HashMap userCache &＃61; new HashMap<>(16); // 全省略方式ArrayList users &＃61; new ArrayList(10);

其实&＃xff0c;初始化泛型对象时&＃xff0c;全省略是不推荐的。这样会避免类型检查&＃xff0c;从而造成上面的问题。

在初始化泛型对象时&＃xff0c;推荐使用 diamond 语法&＃xff0c;代码如下&＃xff1a;

return new PageDataVO<>(totalCount, dataList);

现在&＃xff0c;在 Eclipse 的问题窗口中&＃xff0c;我们会看到这样的错误&＃xff1a;

Cannot infer type arguments for PageDataVO<>

于是&＃xff0c;我们就知道忘记把 List 对象转化为 List 对象了。

4 泛型属性拷贝

Spring 的 BeanUtils.copyProperties 方法&＃xff0c;是一个很好用的属性拷贝工具方法。

问题现象

根据数据库开发规范&＃xff0c;数据库表格必须包含 id&＃xff0c;gmt_create&＃xff0c;gmt_modified 三个字段。其中&＃xff0c;id 这个字段&＃xff0c;可能根据数据量不同&＃xff0c;采用 int 或 long 类型。

首先&＃xff0c;定义了一个 BaseDO 基类&＃xff1a;

/** 基础DO类 */ &＃64;Getter &＃64;Setter &＃64;ToString public class BaseDO {private T id;private Date gmtCreate;private Date gmtModified;}

针对 user 表&＃xff0c;定义了一个 UserDO 类&＃xff1a;

/** 用户DO */ &＃64;Getter &＃64;Setter &＃64;ToString public static class UserDO extends BaseDO { private String name;private String description; }

对于查询接口&＃xff0c;定义了一个 UserVO 类&＃xff1a;

/** 用户VO类 */ &＃64;Getter &＃64;Setter &＃64;ToString public static class UserVO {private Long id;private String name;private String description; }

‍

实现查询用户服务接口&＃xff0c;实现代码如下&＃xff1a;

/** 用户服务类 */ &＃64;Service public class UserService { /** 用户DAO */ &＃64;Autowired private UserDAO userDAO;/** 查询用户 */ public List queryUser(UserQueryVO query) { // 查询用户信息 List userDOList &＃61; userDAO.queryUser(query); if (CollectionUtils.isEmpty()) { return Collections.emptyList(); }// 转化用户列表 List userVOList &＃61; new ArrayList<>(userDOList.size());for (UserDO userDO : userDOList) { UserVO userVO &＃61; new UserVO(); BeanUtils.copyProperties(userDO, userVO); userVOList.add(userVO); }// 返回用户列表return userVOList; } }

通过测试&＃xff0c;我们会发现一个问题——调用查询用户服务接口&＃xff0c;用户 ID 的值并没有返回。

[{"description":"This is a tester.","name":"tester"},...]

问题分析

通过 Debug 模式运行&＃xff0c;进入到 BeanUtils.copyProperties 工具方法内部&＃xff0c;得到以下内容&＃xff1a;

原来&＃xff0c;UserDO 类的 getId 方法返回类型不是 Long 类型&＃xff0c;而是被泛型还原成了 Object 类型。而下面的 ClassUtils.isAssignable 工具方法&＃xff0c;判断是否能够把 Object 类型赋值给 Long 类型&＃xff0c;当然会返回false导致不能进行属性拷贝。

为什么作者不考虑"先获取属性值&＃xff0c;再判断能否赋值”&＃xff1f;建议代码如下&＃xff1a;

Object value &＃61; readMethod.invoke(source); if (Objects.nonNull(value) && ClassUtils.isAssignable(writeMethod.getParameterTypes()[0], value.getClass())) { ... // 赋值相关代码 }

避坑方法

1&＃xff09;不要盲目地相信第三方工具包&＃xff0c;任何工具包都有可能存在问题

在 Java 中&＃xff0c;存在很多第三方工具包&＃xff0c;比如&＃xff1a;Apache 的 commons-lang3、commons-collections&＃xff0c;Google 的 guava……都是很好用的第三方工具包。但是&＃xff0c;不要盲目地相信第三方工具包&＃xff0c;任何工具包都有可能存在问题。

2&＃xff09;如果需要拷贝的属性较少&＃xff0c;可以手动编码进行属性拷贝

用 BeanUtils.copyProperties 反射拷贝属性&＃xff0c;主要优点是节省了代码量&＃xff0c;主要缺点是导致程序性能下降。所以&＃xff0c;如果需要拷贝的属性较少&＃xff0c;可以手动编码进行属性拷贝。

5 Set 对象排重

在 Java 语言中&＃xff0c;Set 数据结构可以用于对象排重&＃xff0c;常见的 Set 类有 HashSet、LinkedHashSet 等。

问题现象

编写了一个城市辅助类&＃xff0c;从 CSV 文件中读取城市数据&＃xff1a;

/** 城市辅助类 */ &＃64;Slf4j public class CityHelper {/** 读取城市 */public static Collection readCities(String fileName) {try (FileInputStream stream &＃61; new FileInputStream(fileName);InputStreamReader reader &＃61; new InputStreamReader(stream, "GBK");CSVParser parser &＃61; new CSVParser(reader, CSVFormat.DEFAULT.withHeader())) {Set citySet &＃61; new HashSet<>(1024);Iterator iterator &＃61; parser.iterator();while (iterator.hasNext()) {citySet.add(parseCity(iterator.next()));}return citySet;} catch (IOException e) {log.warn("读取所有城市异常", e);}return Collections.emptyList();}/** 解析城市 */private static City parseCity(CSVRecord record) {City city &＃61; new City();city.setCode(record.get(0));city.setName(record.get(1));return city;}/** 城市类 */&＃64;Getter&＃64;Setter&＃64;ToStringprivate static class City {/** 城市编码 */private String code;/** 城市名称 */private String name;} }

代码中使用 HashSet 数据结构&＃xff0c;目的是为了避免城市数据重复&＃xff0c;对读取的城市数据进行强制排重。

当输入文件内容如下时&＃xff1a;

编码,名称 010,北京 020,广州 010,北京

解析后的 JSON 结果如下&＃xff1a;

[{"code":"010","name":"北京"},{"code":"020","name":"广州"},{"code":"010","name":"北京"}]

但是&＃xff0c;并没有对城市“北京”进行排重。

问题分析

当向集合 Set 中增加对象时&＃xff0c;首先集合计算要增加对象的 hashCode&＃xff0c;根据该值来得到一个位置用来存放当前对象。如在该位置没有一个对象存在的话&＃xff0c;那么集合 Set 认为该对象在集合中不存在&＃xff0c;直接增加进去。如果在该位置有一个对象存在的话&＃xff0c;接着将准备增加到集合中的对象与该位置上的对象进行 equals 方法比较&＃xff1a;如果该 equals 方法返回 false&＃xff0c;那么集合认为集合中不存在该对象&＃xff0c;就把该对象放在这个对象之后&＃xff1b;如果 equals 方法返回 true&＃xff0c;那么就认为集合中已经存在该对象了&＃xff0c;就不会再将该对象增加到集合中了。所以&＃xff0c;在哈希表中判断两个元素是否重复要使用到 hashCode 方法和 equals 方法。hashCode 方法决定数据在表中的存储位置&＃xff0c;而 equals 方法判断表中是否存在相同的数据。

分析上面的问题&＃xff0c;由于没有重写 City 类的 hashCode 方法和 equals 方法&＃xff0c;就会采用 Object 类的 hashCode 方法和 equals 方法。其实现如下&＃xff1a;

public native int hashCode(); public boolean equals(Object obj) {return (this &＃61;&＃61; obj); }

可以看出&＃xff1a;Object 类的 hashCode 方法是一个本地方法&＃xff0c;返回的是对象地址&＃xff1b;Object 类的 equals 方法只比较对象是否相等。所以&＃xff0c;对于两条完全一样的北京数据&＃xff0c;由于在解析时初始化了不同的 City 对象&＃xff0c;导致 hashCode 方法和 equals 方法值都不一样&＃xff0c;必然被 Set 认为是不同的对象&＃xff0c;所以没有进行排重。

那么&＃xff0c;我们就重写把 City 类的 hashCode 方法和 equals 方法&＃xff0c;代码如下&＃xff1a;

/** 城市类 */ &＃64;Getter &＃64;Setter &＃64;ToString private static class City {/** 城市编码 */private String code;/** 城市名称 */private String name;/** 判断相等 */&＃64;Overridepublic boolean equals(Object obj) {if (obj &＃61;&＃61; this) {return true;}if (Objects.isNull(obj)) {return false;}if (obj.getClass() !&＃61; this.getClass()) {return false;}return Objects.equals(this.code, ((City)obj).code);}/** 哈希编码 */&＃64;Overridepublic int hashCode() {return Objects.hashCode(this.code);} }

重新支持测试程序&＃xff0c;解析后的 JSON 结果如下&＃xff1a;

[{"code":"010","name":"北京"},{"code":"020","name":"广州"}]

结果正确&＃xff0c;已经对城市“北京”进行排重。

避坑方法

1&＃xff09;当确定数据唯一时&＃xff0c;可以使用 List 代替 Set

当确定解析的城市数据唯一时&＃xff0c;就没有必要进行排重操作&＃xff0c;可以直接使用 List 来存储。

List citySet &＃61; new ArrayList<>(1024); Iterator iterator &＃61; parser.iterator(); while (iterator.hasNext()) {citySet.add(parseCity(iterator.next())); } return citySet;

2&＃xff09;当确定数据不唯一时&＃xff0c;可以使用 Map 代替 Set

当确定解析的城市数据不唯一时&＃xff0c;需要安装城市名称进行排重操作&＃xff0c;可以直接使用 Map 进行存储。为什么不建议实现 City 类的 hashCode 方法&＃xff0c;再采用 HashSet 来实现排重呢&＃xff1f;首先&＃xff0c;不希望把业务逻辑放在模型 DO 类中&＃xff1b;其次&＃xff0c;把排重字段放在代码中&＃xff0c;便于代码的阅读、理解和维护。

Map cityMap &＃61; new HashMap<>(1024); Iterator iterator &＃61; parser.iterator(); while (iterator.hasNext()) {City city &＃61; parseCity(iterator.next());cityMap.put(city.getCode(), city); } return cityMap.values();

3&＃xff09;遵循 Java 语言规范&＃xff0c;重写 hashCode 方法和 equals 方法

不重写 hashCode 方法和 equals 方法的自定义类不应该在 Set 中使用。

6 公有方法代理

SpringCGLIB 代理生成的代理类是一个继承被代理类&＃xff0c;通过重写被代理类中的非 final 的方法实现代理。所以&＃xff0c;SpringCGLIB 代理的类不能是 final 类&＃xff0c;代理的方法也不能是 final 方法&＃xff0c;这是由继承机制限制的。

问题现象

这里举例一个简单的例子&＃xff0c;只有超级用户才有删除公司的权限&＃xff0c;并且所有服务函数被 AOP 拦截处理异常。例子代码如下&＃xff1a;

1&＃xff09;UserService.java

/** 用户服务类 */ &＃64;Service public class UserService {/** 超级用户 */private User superUser;/** 设置超级用户 */public void setSuperUser(User superUser) {this.superUser &＃61; superUser;}/** 获取超级用户 */public final User getSuperUser() {return this.superUser;} }

2&＃xff09;CompanyService.java

/** 公司服务类 */ &＃64;Service public class CompanyService {/** 公司DAO */&＃64;Autowiredprivate CompanyDAO companyDAO;/** 用户服务 */&＃64;Autowiredprivate UserService userService;/** 删除公司 */public void deleteCompany(Long companyId, Long operatorId) {// 设置超级用户userService.setSuperUser(new User(0L, "admin", "超级用户"));// 验证超级用户if (!Objects.equals(operatorId, userService.getSuperUser().getId())) {throw new ExampleException("只有超级用户才能删除公司");}// 删除公司信息companyDAO.delete(companyId, operatorId);} }

当我们调用 CompanyService 的 deleteCompany 方法时&＃xff0c;居然也抛出空指针异常 &＃xff08;NullPointerException&＃xff09;&＃xff0c;因为调用 UserService 类的 getSuperUser 方法获取的超级用户为 null。但是&＃xff0c;我们在 CompanyService 类的 deleteCompany 方法中&＃xff0c;每次都通过 UserService 类的 setSuperUser 方法强制指定了超级用户&＃xff0c;按道理通过 UserService 类的 getSuperUser 方法获取到的超级用户不应该为 null。其实&＃xff0c;这个问题也是由 AOP 代理导致的。

问题分析

使用 SpringCGLIB 代理类时&＃xff0c;Spring 会创建一个名为 UserService$$EnhancerBySpringCGLIB$$???????? 的代理类。反编译这个代理类&＃xff0c;得到以下主要代码&＃xff1a;

public class UserService$$EnhancerBySpringCGLIB$$a2c3b345 extends UserService implements SpringProxy, Advised, Factory {......public final void setSuperUser(User var1) {MethodInterceptor var10000 &＃61; this.CGLIB$CALLBACK_0;if (var10000 &＃61;&＃61; null) {CGLIB$BIND_CALLBACKS(this);var10000 &＃61; this.CGLIB$CALLBACK_0;}if (var10000 !&＃61; null) {var10000.intercept(this, CGLIB$setSuperUser$0$Method, new Object[]{var1}, CGLIB$setSuperUser$0$Proxy);} else {super.setSuperUser(var1);}}...... }

可以看出&＃xff0c;这个代理类继承了 UserService 类&＃xff0c;只代理了 setSuperUser 方法&＃xff0c;但是没有代理 getSuperUser 方法。所以&＃xff0c;当我们调用 setSuperUser 方法时&＃xff0c;设置的是原始对象实例的 superUser 字段值&＃xff1b;而当我们调用 getSuperUser 方法时&＃xff0c;获取的是代理对象实例的 superUser 字段值。如果把这两个方法的 final 修饰符互换&＃xff0c;同样存在获取超级用户为 null 的问题。

避坑方法

1&＃xff09;严格遵循 CGLIB 代理规范&＃xff0c;被代理的类和方法不要加 final 修饰符

严格遵循 CGLIB 代理规范&＃xff0c;被代理的类和方法不要加 final 修饰符&＃xff0c;避免动态代理操作对象实例不同&＃xff08;原始对象实例和代理对象实例&＃xff09;&＃xff0c;从而导致数据不一致或空指针问题。

2&＃xff09;缩小 CGLIB 代理类的范围&＃xff0c;能不用被代理的类就不要被代理

缩小 CGLIB 代理类的范围&＃xff0c;能不用被代理的类就不要被代理&＃xff0c;即可以节省内存开销&＃xff0c;又可以提高函数调用效率。

7 公有字段代理

在 fastjson 强制升级到 1.2.60 时踩过一个坑&＃xff0c;作者为了开发快速&＃xff0c;在 ParseConfig 中定义了&＃xff1a;

public class ParseConfig {public final SymbolTable symbolTable &＃61; new SymbolTable(4096);...... }

在我们的项目中继承了该类&＃xff0c;同时又被 AOP 动态代理了&＃xff0c;于是一行代码引起了一场“血案”。

问题现象

仍然使用上章的例子&＃xff0c;但是把获取、设置方法删除&＃xff0c;定义了一个公有字段。例子代码如下&＃xff1a;

1&＃xff09;UserService.java

/** 用户服务类 */ &＃64;Service public class UserService {/** 超级用户 */public final User superUser &＃61; new User(0L, "admin", "超级用户");...... }

2&＃xff09;CompanyService.java

/** 公司服务类 */ &＃64;Service public class CompanyService {/** 公司DAO */&＃64;Autowiredprivate CompanyDAO companyDAO;/** 用户服务 */&＃64;Autowiredprivate UserService userService;/** 删除公司 */public void deleteCompany(Long companyId, Long operatorId) {// 验证超级用户if (!Objects.equals(operatorId, userService.superUser.getId())) {throw new ExampleException("只有超级用户才能删除公司");}// 删除公司信息companyDAO.delete(companyId, operatorId);} }

当我们调用 CompanyService 的 deleteCompany 方法时&＃xff0c;居然抛出空指针异常 &＃xff08;NullPointerException&＃xff09;。经过调试打印&＃xff0c;发现是 UserService 的 superUser 变量为 null。如果把代理删除&＃xff0c;就不会出现空指针异常&＃xff0c;说明这个问题是由 AOP 代理导致的。

问题分析

使用 SpringCGLIB 代理类时&＃xff0c;Spring 会创建一个名为 UserService$$EnhancerBySpringCGLIB$$???????? 的代理类。这个代理类继承了 UserService 类&＃xff0c;并覆盖了 UserService 类中的所有非 final 的 public 的方法。但是&＃xff0c;这个代理类并不调用 super 基类的方法&＃xff1b;相反&＃xff0c;它会创建的一个成员 userService 并指向原始的 UserService 类对象实例。现在&＃xff0c;内存中存在两个对象实例&＃xff1a;一个是原始的 UserService 对象实例&＃xff0c;另一个指向 UserService 的代理对象实例。这个代理类只是一个虚拟代理&＃xff0c;它继承了 UserService 类&＃xff0c;并且具有与 UserService 相同的字段&＃xff0c;但是它从来不会去初始化和使用它们。所以&＃xff0c;一但通过这个代理类对象实例获取公有成员变量时&＃xff0c;将返回一个默认值 null。

避坑方法

1&＃xff09;当确定字段不可变时&＃xff0c;可以定义为公有静态常量

当确定字段不可变时&＃xff0c;可以定义为公有静态常量&＃xff0c;并用类名称 &＃43; 字段名称访问。类名称 &＃43; 字段名称访问公有静态常量&＃xff0c;与类实例的动态代理无关。

2&＃xff09;当确定字段不可变时&＃xff0c;可以定义为私有成员变量

当确定字段不可变时&＃xff0c;可以定义为私有成员变量&＃xff0c;提供一个公有 Getter 方法获取该变量值。当该类实例被动态代理时&＃xff0c;代理方法会调用被代理的 Getter 方法&＃xff0c;从而返回被代理类的成员变量值。

3&＃xff09;遵循 JavaBean 编码规范&＃xff0c;不要定义公有成员变量

遵循 JavaBean 编码规范&＃xff0c;不要定义公有成员变量。JavaBean 规范如下&＃xff1a;

JavaBean 类必须是一个公共类&＃xff0c;并将其访问属性设置为 public&＃xff0c;如&＃xff1a;public class User{......}

JavaBean 类必须有一个空的构造函数&＃xff1a;类中必须有一个不带参数的公用构造器

一个 JavaBean 类不应有公共实例变量&＃xff0c;类变量都为 private&＃xff0c;如&＃xff1a;private Integer id;

属性应该通过一组 getter / setter 方法来访问

后记

最后&＃xff0c;推荐大家阅读一下《Java 开发手册》&＃xff0c;这本手册让我受益匪浅。只要学习理解了《Java 开发手册》&＃xff0c;就能在日常的 Java 开发工作中&＃xff0c;避免踩到很多常识性的 Java 坑。

重磅

泰山版《Java 开发手册》

即将发布

去年 6 月&＃xff0c;《Java 开发手册》发布了华山版&＃xff0c;同时还发布了配套的 IDE 插件&＃xff0c;在全球 Java 开发者的共同努力下&＃xff0c;已成为业界普遍遵循的开发规范&＃xff0c;帮助大家高效开发。《Java 开发手册》背后有哪些故事&＃xff1f;作者孤尽对华山版有哪些解读&＃xff1f;插件该如何使用&＃xff1f;哪里可以下载手册的所有版本&＃xff1f;

继往开来&＃xff0c;在《Java 开发手册》泰山版即将发布之际&＃xff0c;让我们再来全面回顾一下华山版&＃xff0c;识别下方二维码查看&＃xff1a;

福利来了

评论区留言送书

亲爱的同学&＃xff0c;你在写 Java 的过程中遇到过哪些坑&＃xff1f;有什么经验分享&＃xff1f;有没有哪个坑让你终身难忘&＃xff1f;欢迎在评论区留言&＃xff0c;点赞数前 5 名每人随机送出 1 本技术书籍&＃xff0c;周五 13&＃xff1a;00 截止&＃xff0c;祝大家在编程的道路上&＃xff0c;永不踩坑 :)